One important aspect of dynamic provisioning of services on transport networks is signaling of service specific policies and parameters along the path(s), taken by the services.
Currently the GMPLS RSVP-TE protocol (RFC3473) is widely deployed in GMPLS controlled transport networks. The main reason why the said protocol is practically the only choice for GMPLS signaling protocol is because it is derived from the RSVP-TE protocol (RFC3209, RFC2205), which is deployed with great success in IP/MPLS networks in the last 10-12 years. This level of success could be largely credited to the soft state nature of the protocol.
In a nutshell, a soft state signaling protocol requires maintaining of a protocol state for each service on each network interface used by the service. The said state contains all service configuration information and thus fully reflects the current state of the service in the data plane on the interface in question (i.e. network resources currently used by the service, how the resources are configured and bound in cross-connects, etc.). Whenever a service modification is necessary, a new signaling update must be delivered to each service node, carrying full set of service parameters appropriately modified. The protocol software on each node is supposed to use the received information to update the protocol state associated with every interface used by the service, and reconfigure the interfaces accordingly. At the time when the service is not being modified, all nodes involved in the service, are supposed to send and receive periodic refreshes—signaling updates with unmodified content—to/from their respective neighbors. Such refreshes are meant to say that the service is still alive and functioning properly. The refreshes may be missed occasionally; however, if a configured number of subsequent refreshes are not received, this is supposed to be interpreted as the service either has been implicitly deleted or is not functioning. In this case the protocol states on all interfaces used by the service are supposed to be removed, and network resources released. Likewise, any unexpectedly received refresh is supposed to be interpreted as an implicit service setup or reroute, with protocol states and interface configurations are to be adjusted accordingly.
Soft state signaling protocol, such as RSVP-TE, works very well on IP/MPLS networks because of the following network characteristics:                a) Large number of dynamic short-lived flows of traffic that change frequently their paths across the network;        b) Network elements (IP routers) have congruent control and data planes (i.e. use the same network resources for transporting user traffic and control plane messages)        
On such networks soft state signaling protocols provide reasonably reliable self-healing environments that respond equally well to frequently changing service paradigms and various network failures. For example, as soon as a network failure happens, the affected services will stop receiving signaling refreshes. In this case the services will be quickly released on the nodes affected by the failure and re-established shortly along the healthy paths (as soon as IP routing protocols converge, the services are routed away from the failure). In short, the IP/MPLS services, controlled by a soft state signaling protocol, are self-healing and adoptive when affected by network failures and/or network re-configurations, and they self-destroy cleanly and reliably when they are not needed any longer.
Circuit-switched transport networks, however, have very different characteristics compared to IP/MPLS networks. Transport network service placement, re-placement, protection against and restoration after failures need to be tightly controlled. Normally, once set, the services are rarely modified. Importantly, because of non-congruency of the control and data planes of network elements making up transport networks, it cannot be assumed that if a service is disturbed in control plane, it is dysfunctional. In other words, a service may carry user traffic even when the control plane communication between network elements involved in the service is broken. For example, missed signaling refreshes for a given service mean disturbance in the control plane with respect to the service. However, releasing the service just because of the missed refreshes may hit unjustifiably perfectly healthy user traffic flows. So, on the one hand, in sharp contrast to IP/MPLS networks, the soft state nature of a signaling protocol gives no advantages. On the other hand, the price for using a soft state protocol, such as GMPLS RSVP-TE still needs to be paid, which is extremely high in terms of:                a) Memory: RSVP based protocols are notoriously known for huge protocol states, which in case of GMPLS RSVP-TE could be as high as 15Kbyte per state;        b) Bandwidth in DCN (Data Communication Network—a separate IP network used for control and management plane communication between transport network elements and NMS). The scarce DCN resources are consumed by the protocol updates (even at times when the services do not experience any changes);        c) Network element CPU consumed on generating and processing of the large and semantically complex protocol updates (even at times when the services do not experience any changes)        
In addition to being unjustifiably expensive, RSVP-TE based protocols have other serious shortfalls: inflexible signaling paradigm, inability to function under condition of control plane connectivity disruption, inability to signal incremental and sequence critical modifications, lack of message flow control, etc.
There are only two ways to manipulate services (creating/modifying/deleting) using a conventional RSVP-TE based signaling protocol as illustrated in FIG. 1:                a) One-way end to end: starting on service ingress node, then hop-by-hop to every transit node and finishing on the service egress node;        b) Two-way end to end: starting on the ingress node, then hop-by-hop to every transit node, then reversing direction on egress node and going back hop-by-hop over all transit nodes and finishing on the ingress node.        
When using a conventional RSVP-TE based signaling protocol it is impossible to realize many useful signaling patterns such as shown in FIG. 2, in particular:                a) end to end from egress node hop-by-hop towards ingress node;        b) start from a transit node in either or both directions;        c) scope signaling to a path segment (as opposed to end-to end);        d) scope signaling to an arbitrary subset of service nodes;        e) star-n-spoke paradigm (used by the management plane when the service provisioning is controlled by NMS): signal separately to each service node.        
Further RSVP-TE is not able to handle control plane connectivity disruptions.
RSVP-TE based protocols function hop-by-hop. If one of the RSVP-TE controllers along a service path has stopped working for whatever reason, the signaling flow is disrupted, and the service becomes unmanageable (albeit remains functional in the data plane). For example, a RSVP-TE based protocol provides no clean way to tear down, modify or reroute a service without straying the network resources allocated for the service, when one of the RSVP-TE controllers along the service path has crashed because of a hardware failure or a software bug. This is a serious operational problem, exacerbated even further by the lack of a mechanism to notify the management plane (and eventually the user) about control plane connectivity problems.
Moreover RSVP-TE to is not able to signal incremental and/or sequence critical updates.
Because RSVP-TE service setup or modify message (Path message) must contain entire information about service (full control plane state), and because RSVP-TE messages could be occasionally lost even under normal—network failure free—conditions (due to unreliable IP datagram transport used by RSVP-TE), it is impossible to signal service changes in increments. Furthermore, for the same reasons and also because RSVP-TE does not mandate any order as to how the RSVP-TE objects should appear in the message, it is awkward to signal via RSVP-TE provisioning operations that require a certain sequence in which they must be performed.
There is also a lack of message flow control in RSVP-TE.
RSVP-TE based protocols do not have message flow control because of the IP datagram based transport used by RSVP-TE to propagate its messages along the service path. For example, the situation can arise when frequent service modifications signaled by a service ingress RSVP-TE controller overwhelms a slower neighboring transit node. Note that this problem does not exist when a protocol uses TCP based transport to distribute its messages. BGP and LDP are two popular examples of such protocol.